home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 5081 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.6 KB
  1. Path: mips.pfalz.de!not-for-mail
  2. From: naddy@mips.pfalz.de (Christian Weisgerber)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Better UARTs?
  5. Date: 21 Feb 1996 14:51:42 +0100
  6. Message-ID: <4gf81e$vhu@mips.pfalz.de>
  7. References: <4g0hq5$166u@usenetw1.news.prodigy.com>
  8. NNTP-Posting-Host: mips.pfalz.de
  9.  
  10. davidsen@tmr.com (bill davidsen) writes:
  11.  
  12. > It seems that in addition to a 64 byte FIFO (no surprise) it will do
  13. > the hardware handshake for you! Now the slowest system around will
  14. > not lose data because the UART will drop RTS when the FIFO is almost
  15. > full, and will stop sending if the CTS drops. This is where the
  16. > logic should have been all along,
  17.  
  18. Actually, TI has had out a 16550C implementing Auto-CTS and Auto-RTR/CTS
  19. for quite some time. (I've been mentioning the '550C and '750 in this
  20. group ever since I got the respective spec sheets.)
  21.  
  22. > Any experience with these?
  23.  
  24. Unfortunately I haven't gotten around to digging one up.
  25.  
  26. > The larger buffer is nice, but the flow control changes the whole
  27. > dynamics of how UARTs are handled.
  28.  
  29. In Auto-RTR/CTS mode, whenever the FIFO fills up to its IRQ trigger
  30. threshold the chip takes RTR low. Supposedly there are modems out there
  31. that can't handle this rate of flow control change (seems they've got
  32. their RTR input wired to an interrupt line and can't handle that many
  33. IRQs). I haven't heard anything specific, though.
  34.  
  35. -- 
  36. Christian 'naddy' Weisgerber                         naddy@mips.pfalz.de
  37.   See another pointless homepage at <URL:http://home.pages.de/~naddy/>.
  38.        -- currently reading: Timothy Zahn, Conquerors' Heritage --
  39.